1. Field of the Invention
The present invention relates to a network relaying method and device, and in particular to a network relaying method and device at the time of distributing data from a server to a client by multicast.
2. Description of the Related Art
Together with a recent rapid spread of a personal computer, an intranet has been expanding, while a computer and a network themselves have become advanced and sophisticated. Also, the spread of web pages (WWW) and multimedia data such as moving images and voices have been rapidly advanced.
Furthermore, the spread of a broadband network has been recently advanced in accesses over the Internet including enterprise users and general users. The use of the voices and the moving images so-called multimedia, and a business form by distributing and broadcasting services using the multimedia have been increasing.
Presently, in the course of spread, a method of distributing data to each user by a unicast technology has been used in many cases. Especially in the moving image distribution accessed by numerous users, a mechanism in which numerous servers are set in data distribution sources, or a cache server is provided in every area and the users receive data from an adjoining cache server is adopted for the purpose of load balancing.
This is applied to an on-demand broadcasting and a real-time broadcasting. In order to provide quality which satisfies numerous users, numerous facilities and a large amount of investment are required.
On the other hand, in order to efficiently transmit large amounts of data, a data transmission by a “multicast” technology has begun to be performed. It is expected that a multimedia data transmission using the multicast is spreading more and more.
While the multicast can not perform an on-demand distribution basically, it has numerous merits in a real-time moving image distribution and voice distribution such as live broadcasting.
Namely, in the multicast distribution, as shown in FIG. 1, a server S1 can make numerous clients R1, R2, . . . receive data through multicast routers 1_1 and 1_2 (hereinafter, occasionally represented by a reference numeral “1”) and LAN switches SW1, SW2 (hereinafter, occasionally represented by a reference numeral “SW”) only by transmitting a single stream to a multicast-capable network MNW, regardless of the number of users (clients) who receive the data.
Accordingly, it is not necessary to provide a cache in each location, and a bandwidth in each network can be saved different from the unicast.
Put another way, a traffic amount of a certain path can be kept fixed regardless of the number of users, little influence is exerted on other communications, and facilities such as a network and a cache server specific to a distribution are not required different from the case of the unicast, so that it becomes possible to distribute the multimedia data very inexpensively.
There is a restriction that an entire network ranging from the server to the client is required to support the multicast. However, presently, the support for the multicast has almost been completed in a relaying device and a data distribution server set on the network, or all of the personal computers used by clients. It is expected that the ratio of the multicast usage becomes gradually higher especially in the moving image distribution and the voice distribution in a real-time broadcasting form.
Hereinafter, a summary of an environment and a mechanism of the multicast data distribution will be described.
Specifically, an IP multicast address (group address), a multicast address of a data link layer, an IGMP (Internet Group Management Protocol) that is a protocol between a client (host) and a multicast router, and a multicast routing protocol constructing a multicast distribution tree within the network will now be described respectively. It is to be noted that the data link layer will be described for an Ethernet.
An IP multicast distribution uses the multicast address, functions between clients R1, R2 and a multicast router 1 as shown in FIGS. 28A and 28B, and is realized by operating the IGMP, which provides a function that the router 1 grasps the multicast group of the subordinate clients R1 and R2 and the multicast routing protocol which constructs a multicast data distribution tree from the server to a plurality of receiving clients between routers.
The IGMP is a protocol with which the router 1 grasps/manages whether or not a receiving client exists in a local network to which the router itself belongs by transferring an IGMP message of a packet format shown in FIG. 29 between the clients R1, R2 and the router 1.
Put another way, the IGMP is a protocol between the router and the client for informing the router 1 that the clients R1 and R2 join a certain multicast group. Both of the router and the clients are required to mount a function specified by the IGMP (applied when a “protocol ID” in an IP header shown in FIG. 30 is “2”). An IGMPv1 is specified in an appendix 1 of RFC 1112, an IGMPv2 is specified in RFC 2236, and an IGMPv3 is being standardized in IETF.
The multicast routing protocol is a protocol between routers for a path control (or arrangement of a path tree) determining to which interface of the router 1 multicast data are copied in order for the router 1 to distribute a multicast data stream to the receiving clients R1 and R2 in a network composed of a plurality of multicast routers 1 and the layer 3 switches SW as shown in FIG. 1.
As for its type, there are DVMRP (used in MBone, specified in RFC 1075), PIM (specified in RFC 2117; new version IETF is being reviewed), MOSPF (operable only on OSFP, specified in RFC 1584 and 1585), and the like.
It is to be noted that the above-mentioned RFC 1112 has a function of mapping between an IP address of a class D, i.e. a multicast IP address and a multicast physical address, and a filtering function of receiving only a packet of a specific multicast physical address and of transferring the packet to an upper layer.
A correspondence between the multicast IP address and the multicast physical address is specified (in RFC 1700) to put lower 23 bits of the multicast IP address into the lower 23 bits of the multicast physical address “01.00.5E.00.00.0016”. For example, the multicast IP address “239.133.130.34” is the multicast physical address “01:00:5E:05:82:22”.
Also, the multicast address (IPv4) is specified as a class D address, in a range from “224.0.0.0” to “239.259.255.255” by a decimal notation.
FIG. 31 shows the IP address of the class D. The class D address is identified with the first 4 bits “1110”. As shown in FIG. 31, some multicast addresses are reserved for specific usages.
Addresses assigned to local sites, i.e. from “239.0.0.0” to “239.255.255.255” are IP multicast addresses generally used by e.g. an enterprise network, an ISP, and the like.
A distribution procedure of the above-mentioned multicast data will now be simply described by referring to FIGS. 28A and 28B.
[1] Join to Multicast Group
(1) In order to query the clients R1 and R2 connected to the local network as to a join to a multicast group, the multicast router 1 periodically transmits to “224.0.0.1” (All-Systems-Group) an “HMQ (Host Membership Query)” message (see {circle around (1)} in FIG. 28A) in which a type value is “0x11” within an IGMP header of a packet in a format (IGMPv2) shown in FIG. 29.(2) A client which desires the join to the multicast group responds to the above-mentioned “HMQ”. In order to inform the multicast address of a group which the client desires to join, the client transmits an “HMR (Host Membership Report)” message (see {circle around (2)} in FIG. 28A) whose type value is “0x12” within the IGMP header of the packet in the same format to the multicast address which the client joins.
Receiving this message, the multicast router 1 grasps the multicast group (identified by the above-mentioned class D address) which the client joins, and starts the transmission of multicast data (stream) to the local network.
[2] Multicast Data Distribution
(1) On the other hand, a transmitting server such as the server S1 in FIG. 1 of the multicast data transmits “single” data (stream) to the multicast group identified with the class D address.
(2) The multicast router 1 within the network copies the data stream addressed to the group as required to be transmitted along the path to each receiving client which joins the multicast group.
Put another way, the multicast data are distributed along the path tree, formed by a multicast routing protocol, of the multicast data distribution from the transmitting server to each receiving client. Finally, the “single” data stream transmitted by the server is distributed to “a plurality of” clients within the network.
[3] Leave from Multicast Group
(1) A client which desires to leave the multicast group, which the client has joined, transmits a “leave” message (see (I in FIG. 28B) as shown in FIG. 28B to “224.0.0.2” (All-Routers-Group) at the time of determining the leave.
(2) In order to confirm that there is no other client which has joined the multicast group, the multicast router 1 having received the “leave” message transmits a “GS-Q (Group Specific Query)” message (see {circle around (4)} in FIG. 28B) by designating the group address.
If there is another client which has joined the group except the client which has transmitted the “leave” message in this case, the other client transmits the “HMR” message to inform its existence to the multicast router 1.
While there are numerous merits in the data and contents distribution using the multicast, the management of an individual user is difficult since a server does not transmit data to each client different from the case of the unicast, and the multicast itself uses a UDP (User Data Protocol) packet.
The difficulty of the management means that it is impossible to grasp e.g. the number of receiving clients at a certain time, and how long (from when until when) each client has received data, and to acquire and manage information of the client itself.
Accordingly, it has been impossible to collect information for reviewing which content is popular and how many clients have received the content, and to realize charging in accordance with a time of a data reception as a service form.